Add opt-in CJK text rendering support to Mod.dll#35
Conversation
The retail Engine.dll is an ANSI build: text drawing iterates strings byte by byte, so CharRemap keys above 0xFF can never be produced and DBCS text renders as blanks. This detours UCanvas::WrappedPrint, UCanvas::ClippedPrint (the menu text path), UCanvas::ClippedStrLen and FCanvasUtil::DrawString with reimplementations that pair GBK/Shift-JIS lead+trail bytes into 16-bit CharRemap keys - the same scheme the official Japanese release used with its modified Engine.dll. The hooks are only installed when the new EnableCJKText config property on SWRCFix is set (System.ini [Mod.SWRCFix], default off), so existing installs are unaffected: DBCS pairing could otherwise mis-pair extended-Latin bytes in the EFIGS localizations (e.g. 0xFC followed by a trail-range byte).
|
Hello there, Thanks for the pull request. \Mod\Src\CJKText.cpp(51): error C4234: nonstandard extension used : '__thiscall' keyword reserved for future use |
|
Hi, Thanks for testing with VS2003. I pushed a compatibility fix. I originally built and tested this with VS2022. I’ve now removed the explicit __thiscall function pointer typedefs and replaced them with VS2003-friendly call patterns. I also cleaned non-ASCII comment punctuation and trailing whitespace. I re-tested the converted VS2022 project successfully, but I don’t have a VS2003 environment locally, so please re-run the VS2003 build when convenient. |
|
Now it compiles fine. https://dl.swrc-modding.net/apps/files/files/425?dir=/SWRC/Translations |
|
Based on the current commit, three things are required for the font to work:
[Mod.SWRCFix]
You should not need to change the Windows system language/locale. The important part is the file encoding. The current hook does not decode UTF-8/Unicode; it only pairs DBCS lead/trail bytes into the 16-bit CharRemap key used by the font, so UTF-8 byte sequences will not match the font remap table. 
Thai is not supported by this hook. This approach is only suitable for CJK-related DBCS encodings/languages. Also, one thing I realized: my encoding analysis was based on an official Japanese language pack that directly replaces the *.int files, so I missed the existing [Engine.Engine] Language=... mechanism for loading language-specific extensions. That is why I added the explicit EnableCJKText option, but this requires rebuilding Mod.u, which is not ideal. Do you think it would be better to change the hook so it automatically enables itself when Language is set to a CJK extension such as cht or jpt? The Chinese font file is quite large because of the number of Chinese glyphs. I will optimize it first and upload it soon. |
2 participants
The retail Engine.dll is an ANSI build: the canvas text functions walk strings byte by byte, so font
CharRemapkeys above 0xFF can never be produced and double-byte (GBK / Shift-JIS) text renders as blanks. The official Japanese release solved this by shipping a modified Engine.dll.This instead detours four Engine exports from Mod.dll with DBCS-aware reimplementations —
UCanvas::WrappedPrint,UCanvas::ClippedPrintUCanvas::ClippedStrLenandFCanvasUtil::DrawString— pairing lead+trail bytes into 16-bit CharRemap keys, the same scheme the JP release used. Struct layouts follow the Engine.dll decompilation (reference offsets noted in comments), and exports are resolved by name rather than hardcoded addresses.Off by default: the hooks are only installed when
EnableCJKText=Trueis set under[Mod.SWRCFix]in System.ini, so existing installs are unaffected (unconditional pairing could mis-pair extended-Latin bytes in EFIGS text).Tested on the Steam build with a Simplified Chinese font and localization: menus, title cards, loading screens, hints, briefing and in-game subtitles all render correctly; single-byte text is unchanged with the flag on or off.